Method and server for downloading a broadcasted multimedia content over a distribution network

ABSTRACT

The invention applies to the transmission of a multimedia content from a server to a client terminal. The multimedia content is available from the server as one or more sets of files. Upon reception of an initial request from the client, the server sends a document back to the client, said document causing the client to repetitively send fetching request. Upon reception of a fetching request, the server selects the file to download.

FIELD OF THE INVENTION

The present invention relates to a method for downloading a multimediacontent to a client device.

The invention also relates to a computer program comprising instructionsfor implementing such a method when executed by a processor.

The invention also relates to a server and a network system specificallydesigned for downloading a multimedia content to a client device.

The invention has interesting applications for the transmission ofmultimedia contents (including live contents like live events orbroadcasted TV programs) to client devices via the Internet. It alsoapplies to the transmission of video from one mobile device to one ormore peer devices via the Internet.

BACKGROUND OF THE INVENTION

The international patent application WO02/49343 describes a method fortransmitting to a terminal audio or video material that is stored on aremote server as a set of files representing successive temporalportions of said material.

In the described method, the terminal is responsible for determiningwhich file it wants to receive and requesting each file one by one.

This solutions has two main drawbacks: first, the terminal must bespecifically designed for implementing the proposed distribution method,and second the server doesn't have any control of which file isdownloaded.

One of the objects of the present invention is to propose an alternativedistribution method that doesn't have the above mentioned problems.

SUMMARY OF THE INVENTION

This is achieved with a server as defined in claims 1 to 4, adownloading method as defined in claims 5 to 8, a network system asdefined in claim 9, and a computer program as defined in claim 10.

According to the invention, upon reception of an initial requestdirected to a multimedia content from a client device, the server sendsa document back to the client device. This document causes the clientdevice to repetitively send fetching requests. Upon reception of thefetching requests, the server selects which file is to be downloaded.

The fetching requests of the invention don't indicate any specific fileto be downloaded. They are just a request for the next file.

One advantage of having the client device send a fetching request foreach file to be downloaded is that this way of operating is supported byall client browsers (some browsers may not support receiving severalfiles in response to one single request and therefore it is preferrednot to have the server send the files one by one upon reception on asingle request by the client device).

With the invention, the client device is caused to send the fetchingrequest by the document received from the server. This means that theclient device doesn't have to be specifically designed to send thefetching requests. Any standard client device can implement theinvention.

The invention proposes to generate one or more set of files for the samemultimedia content, with slicing positions that vary from one set toanother (the files are starting at different positions in time in eachset). When a client sends an initial request directed to a live content,he receives either the previous file—which means he will receive out ofdate information—or he has to wait for the next file to be ready. Inboth cases, using several sets of files allows reducing theinconvenience for the user. The number of sets is a compromise betweenthe inconvenience experienced by the client and the storage unit spaceneeded to store the files.

File-based contents are transmitted from a server to a client device viaa point-to-point connection. On IP networks, point-to-point connectionsare usually ruled by the HTTP protocol (Hyper Text Transfer Protocol,defined in the RFC2616 of the IETF). HTTP is a stateless protocol andtherefore HTTP requests issued by the same client device are normallyprocessed independently one from the other.

The embodiment of claims 2 and 6 allows the server to keep track of eachclient. As the server knows which file is to be sent next for eachclient, smooth playback of the content may be achieved, even whenseveral sets of files are available.

The embodiment defined in claims 4 and 8 has advantage of allowing theclient device to request jumps in the sequence of files in any fetchingrequest.

BRIEF DESCRIPTION OF THE FIGURES

These and other aspects of the invention are further described byreference to the following drawings:

FIG. 1 is a schematic representation of a first example of networksystem according to the invention,

FIG. 2 is a schematic representation of a plurality of sets of filesgenerated by a slicer according to the invention,

FIG. 3 is a schematic representation of two overlapping files,

FIG. 4 is schematic representation of three sets of files,

FIG. 5 is a block diagram of a method according to the invention fordownloading a live multimedia content,

FIG. 6 and 7 are schematic representations of other examples of anetwork system according to the invention.

DESCRIPTION OF PREFERRED EMBODIMENT

FIG. 1 is a schematic representation of a network system according tothe invention. The network system of FIG. 1 comprises:

-   a source 1 for acquiring a multimedia content;-   a broadcaster 2 for broadcasting said multimedia content;-   a receiver 3 for receiving a broadcasted multimedia content;-   an encoding system 4 comprising an encoder 5 for encoding a received    multimedia content, and a slicer 6 for slicing an encoded multimedia    content in at least one set of slicing positions forming at least    one set of slices that can be decoded independently one from the    other, and for enclosing each slice in a file thereby generating at    least one set of files,-   a server 8 having access to said files,-   a distribution network 10, the server 8 being linked to the    distribution network 10,-   an access provider 12 for providing a client device 14 with an    access to the distribution network 10.

The client device 14 has (amongst other means not represented in FIG. 1)a communication unit 15 for transmission/reception to/from the accessprovider 12, a player 16 for playing an encoded multimedia content, anda display 17 for displaying a multimedia content. The client device 14can be either a mobile device (like a mobile phone) in which case thecommunication unit 15 is a radio communication unit, or a wired device(like a PC) in which case the communication unit 15 is a wiredcommunication unit. The distribution network 10 is typically theInternet network.

For instance the broadcaster 2 is a satellite broadcasting network andthe receiver 3 is a satellite receiver. This is not restrictive: anyother broadcasting means could be used instead of satellite broadcastingmeans. The broadcasted multimedia content can be any multimedia contentthat is transmitted and can be received by a number of receiversincluding the receiver 3. For instance the broadcasted multimediacontent can be a television program, a pre-recorded event/program, alive event . . .

The encoder 5 is responsible for encoding the received multimediacontent. For instance the encoder 5 is compliant with one of the MPEGstandards, or with H263.

The encoder 5 and the slicer 6 are either implemented in a single deviceor in two separated devices. In both cases, what is transmitted from theencoder 5 to the slicer 6 is an encoded video stream. Advantageouslythis encoded video stream is transmitted from the encoder 5 to theslicer 6 over IP by using the RTP protocol. This is not restrictive. Byway of example, the transport layer of the MPEG-2 standard, known asMPEG-2 TS, could be used as well.

In practice, the files generated by the slicer 6 are stored in a storageunit 20 to which the server 8 has access. The storage unit 20 is sharedby the slicer 6 and the server 8. The storage unit 20 can be part of theserver equipment or can be located remotely.

The function of the slicer 6 is to slice the encoded content generatedby the encoder 5 into a plurality of slices where each slice comprises agiven amount of time of the encoded multimedia content and can bedecoded independently from the other slices. In practice, any encodedmultimedia content generated by a multimedia encoder comprises so-calledRandom Access Points (RAP). In order to produce slices that can bedecoded independently one from the others, the slicer 6 slices theencoded multimedia content in such a way that each slice starts with aRandom Access Point. For instance, when the encoder is compliant withthe MPEG-2 or MPEG-4 standard, the random access points are the I-framesof the MPEG-encoded multimedia content, and the slicing positions arechosen in such a way that the first frame of each slice is an I-frame.

Because the slices can be decoded independently one from the other, theclient doesn't need to receive the content from its beginning. It canstart receiving the content from any slice. Therefore the invention isapplicable to the transmission of live content, that is content that ismade available at the server side in real-time (for example a live eventlike a championship or a show, or broadcasted program . . . ).

Advantageously the size of the slices is adjustable. It may be identicalfor all slices or it may vary from one slice to another (for instancethe size of the slices may increase along time). The best efficiency isobtained with files that are relatively long because the more files tobe transported the more overhead due to file headers.

Each slice generated by the slicer 6 is stored as a file in the storageunit 20. The storage unit 20 has to be “cleaned” on a regular basis toensure that there is available room for storing the newly generatedfiles. A way of cleaning the storage unit is to re-use file names on aregular basis. An alternative way is to use different file names foreach file, and to delete the aging files on a regular basis.

According to the invention the slicer 6 generates either one set offiles or a plurality of sets of files for the same multimedia content.When the slicer 6 generates a plurality of sets of files, a plurality ofsets of slicing positions are used, each set of slicing positions beingshifted in time compared with the other sets of slicing positions. FIG.2 is an illustration of a plurality of sets of files S₁, S₂, . . . ,S_(N) generated by the slicer 6. Each set of files S_(i) comprises Kfiles F_(ij (i=)1, . . . ,N; j=1, . . . , K). A set of slicing positions{T_(i,l), . . . , T_(i,K)) is associated to each set of files S_(i). Asillustrated in FIG. 2, the slicing positions T_(i+1j) are shifted intime compared to the slicing positions T_(ij) (the axis t is the timeaxis). In other words, the files F_(i+1j) and F_(i,j) are overlapping(they comprise identical encoded data). In FIG. 3, the overlap betweenthe files F_(i+1j) and F_(i,j) is indicated by an arrow O_(i+1).

As will be apparent in the description below generating a plurality ofsets of files is advantageous because it allows reducing the delayexperienced by the client when he/she sends a request for a livecontent.

The server 8 is linked to the distribution network 10. The client device14 has access to the distribution network 10 via the access provider 12.Typically, the client device 14 can load through the distributionnetwork 10 a page containing at least one link to a multimedia contentthat the server 8 offers to download. When a user clicks on said link,an initial request R₀ directed to said multimedia content is sentautomatically to the server 8. There are several possible ways for theserver 8 to handle the initial request R₀.

In a first embodiment of the invention, upon reception of the initialrequest R₀, the server 8 sends a document to the client device 14. Thisdocument causes the client device 14 to repetitively send a fetchingrequest designating the multimedia content.

By way of example, the document sent by the server 8 can be a pagecomprising an automatic refresh command. An example of such a page isgiven below: <html> <head> <META meta http-equiv=“Refresh”content=“134”; url=‘http://www.yoursite.com/live2download.html”’ </head><embed src=“live2download.mp4” width=“240” height=“240”> </embed></html>

Such a page causes the client browser to reload the file“live2download.mp4” every 134 seconds (which is the duration of a filein this example).

Alternatively, the document sent by the server 8 can be a standarddescription of the multimedia content, said standard description beingintended to be processed by the player 16 in a standard way. Forinstance such a description can be a SMIL description (SMIL is a W3Cstandard defining XML-based audio/video scene descriptions). An exampleof such a SMIL description is given below: <smi1> <head> <layout><root-layout width=“240” height=“240” background-color=“white”/> <regionregionName=“im” left=“0” top=“0” width=“240” height“240”/> </layout></head> <body> <seq repeatCount = “indefinite” > <video id=“vid”src=“live2download.mp4” region=“im” /> </seq> </body> </smi1>

The effect of this SMIL document is to cause the player 16 to play thefile “live2download.mp4” repetitively. As a result the client devicewill repetitively send fetching requests directed to the file“live2download.mp4”.

Advantageously, the SMIL document sent by the server 8 comprises acommand indicating that the files have to be fetched some time inadvance (that is some time before the end of the playback of theprevious file). This ensures that the next file will arrive on time atthe client device 14 so that the client will not experience a gap in therendering of the multimedia content. An example of a SMIL descriptionhaving such a command is given below: <smi1> <head> <layout><root-layout width=“240” height=“240” background-color=“white”/> <regionregionName=“im” left=“0” top=“0” width=“240” height=“240” /> </layout></head> <body> <seq repeatCount = “indefinite” > <video id=“vid”src=“live2download1.mp4” region=“im” clipBegin =“0s” dur =“25s” /> <par><prefetch src=“live2download2.mp4” mediaTime =“5s” /> <video id=“vid”src=“live2download1.mp4” region=“im” clipBegin = “25s” /> </par> <videoid=“vid” src=“live2download2.mp4” region=“im” clipBegin =“0s” dur =“25s” /> <par> <prefetch src=“live2download1.mp4” mediaTime =“5s” /><video id=“vid” src=“live2download2.mp4” region=“im” clipBegin = “25s”/> </par> </seq> </body> </smi1>

This document is written for slices containing 30 s of content. Itcauses the player to execute the following operations in sequence:

-   a) playing the first 25 s of a first source (live2download1.mp4);-   b) playing the last 5 s of the first source and in parallel fetching    the first 5 s of a second source (live2download2.mp4);-   c) playing the first 25 s of the second source (which can be done    without delay since the first 5 s have been pre-fetched).    Using two different sources is an implementation trick. The server 8    must be designed to recognize that the first and the second sources    correspond to the same encoded multimedia content.

The server has to select a file to download upon reception of thefetching requests. The server 8 can either select the most recent fileor the first file to get ready. The consequence of selecting the mostrecent file is that the client will receive out-of-date data. Theconsequence of selecting the first file to get ready is that the clientwill have to wait a certain time before getting a response. In both casethe inconvenience for the client is reduced when several sets of filesare used. This is illustrated in FIG. 4.

In FIG. 4, three sets of files S₁, S₂ and S₃ are represented. An arrow Aindicates the reception of a request by the server 8.

When the only set to be generated by the slicer 6 is the first set S₁,the server 8 will either download the file F_(1,1) (the most recentfile) or the file F_(1,2) (the next file to get ready). If the server 8downloads the file F_(1,1), then the data received by the client will belate by a time equal to a_(1,1). If the server downloads the fileF_(1,2), then the client will experience a delay equal to b_(1,2) beforereceiving the data.

When the three sets S₁, S₂ and S₃ are generated by the slicer 6, theserver 8 will either download the file F_(2,1) (the most recent file) orthe file F_(3,2) (the next file to get ready). If the server 8 downloadsthe file F_(2,1), then the data received by the client will be late by atime equal to a_(2,1). If the server downloads the file F_(3,2,) thenthe client will experience a delay equal to b_(3,2) before receiving thedata. It can be seen that a_(1,1)>a_(2,1) and b_(1,2)>b_(3,2).

The transmissions over the distribution network 10 are ruled by the HTTPprotocol. HTTP is a stateless protocol and therefore HTTP requestsissued by the same client device are normally processed independentlyone from the other. As a result, there is a risk that the playback ofthe content cannot be achieved smoothly when several sets of files areavailable (some parts of the content may be received several times, orsome parts of the content may be missing). A second embodiment of theinvention will now be described that solves this problem.

In the second embodiment of the invention, the document sent by theserver 8 in response to the initial request R₀ comprises a resourceidentifier designating the encoded multimedia content asked by theclient. This resource identifier is specific to the client device 14.The document sent by the server 8 causes the client device 14 torepetitively send a fetching request containing this resourceidentifier. Upon reception of the first fetching request, the server 8selects the file to be downloaded as described above (it selects eitherthe most recent file or the next file to get ready). The server 8downloads the selected file and keeps a record of which file wasdownloaded (or alternatively which file is next to be downloaded). Uponreception of subsequent fetching requests containing the same resourceidentifier, the server 8 checks the record to select the next file todownload, downloads the selected file and updates the record.

In this way, each client device 14 will receive a sequence of files thatis complete and correctly ordered (all the received files areconsecutive files belonging to the same set of files).

By way of example the resource identifier comprised in the document sentby the server 8 can be a “nonce” as defined in the RFC1510 of the IETF(a nonce is a number that is used only once). An example of a SMILdocument comprising such a resource identifier is given below: <smi1><head> <layout> <root-layout width=“240” height=“240”background-color=“white”/> <region regionName=“im” left=“0” top = “0”width=“240” height = “240” /> </layout> </head> <body> <seq repeatCount= “indefinite” > <video id=“vid” src=“cnn142299293873635534291919.mp4”region= “im” /> </seq> </body> </smi1>

Here the resource identifier is cnn142299293873635534291919. The clientdevice 14 will repetitively send fetching requests for the filecnn142299293873635534291919.mp4. The server 8 will keep track of whichfile was downloaded (or is to be downloaded) for the resource identifiercnn142299293873635534291919.

In a third embodiment of the invention, the fetching request sent by theclient device may contain a jump indication (a backward or a forwardcommand). For example, such a backward or forward command is input bythe client by moving a cursor on a sliding bar. An indication of theposition or displacement of the cursor is then included in the fetchingrequest. It is used by the server together with the resource identifierto determine the file to download.

The steps that have been discussed above are summarized in FIG. 5.According to FIG. 5, a method according to the invention for downloadinga multimedia content M comprises:

-   a step X1 of producing an encoded a multimedia content E(M),-   a step X2 of slicing the encoded multimedia content E(M) in at least    one set of slicing positions forming at least one set of slices that    can be decoded independently one from the other, and enclosing each    slice in a file F_(ij) thereby generating at least one set of files    S₁, S₂, . . . , S_(N)-   a step X3 of sending a document DOC to said client device upon    reception of said initial request R₀, said document causing said    client device to repetitively send a fetching request R_(t)(t=0, . .    . , P with P being an integer) that designates said multimedia    content,-   a step X4 of selecting at least one file F_(ij) amongst said set(s)    of files, upon reception of said fetching requests from said client    device, and downloading the selected file(s) to the client device.

These steps are implemented by way of specific hardware and/or softwarecomprised in one or several devices. For instance in FIG. 1, step X1 isimplemented by the encoder 5, step X2 is implemented by the slicer 6,and steps X3 to X4 are implemented by the server 8.

Two other examples of a network system according to the invention willnow be described by reference to FIGS. 6 and 7.

The network system of FIG. 6 comprises a first client device 50, adistribution network 52, a second client device 54, and at least oneaccess provider 56 for providing the first and the second client devices50 and 54 with an access to the distribution network 52.

The second client device 54 is similar to the client device 14 describedby reference to FIG. 1. Typically the distribution network 52 is theInternet network.

The first client device 50 comprises:

-   a source 60 for acquiring a multimedia content,-   an encoder 62 for encoding an acquired multimedia content,-   a slicer 64 for slicing an encoded multimedia content in at least    one set of slicing positions forming at least one set of slices that    can be decoded independently from the others, and for enclosing each    slice in a file thereby generating at least one set of files,-   a server 66 having access to said files,-   a communication unit 68 for transmission/reception to/from the    access provider 56.

Typically the first client device is a mobile phone, which means thatthe communication unit 68 is a radio communication unit.

The functionalities of the source 60, the encoder 62, the slicer 64 andthe server 66 are identical to the functionalities of the source 1, theencoder 5, the slicer 6 and the server 8 described above by reference toFIGS. 1 to 4.

FIG. 7 gives a schematic representation of an alternative solution wherethe server 66 is located in the distribution network 52 instead of beinglocated in the first client device 50. In this embodiment, the firstclient device 50 will upload the files generated by the slicer 64 to theserver 66, and the server 66 will in turn download at least one thefiles to the second client device 54.

Typically the first client 50 sends a link toward an encoded multimediacontent (for instance a video that is being captured by the first clientdevice 50) to the second client device 54, for instance via SMS (ShortMessage Service). When the second client clicks on the link contained inthe SMS, an initial request directed to the encoded multimedia contentis sent to the first client device 50. Upon reception of this initialrequest, the first client device 50 operates as described above withreference to FIGS. 1 to 4.

Modifications or improvements may be proposed with respect to thedescribed network system, server, system, slicer, client device, anddownloading method without departing from the scope of the invention.The invention is thus not limited to the examples provided.

In particular the “progressive downloading” concept disclosed in theEuropean patent application n° 03290453.4 filed on May 07, 2003 byKoninklijke Philips Electronics N.V. can be combined with presentinvention. When a file generated by the slicer 6 is progressivelydownloaded, the player 16 doesn't need to wait until the file iscompletely downloaded to start playing the file.

The use of the verb “comprise” in the description and in the claims doesnot exclude the presence of other elements or steps than those listed inthe description and in the claims. The use of the article “an” or “a”preceding an element or step does not preclude the presence of aplurality of such element or step.

1. A server (8) having access to at least one set of files (S_(i))generated by slicing an encoded multimedia content in at least one setof slicing positions ({T_(i,1), . . . , T_(i,K)}) forming slices thatcan be decoded independently one from the other, and by enclosing eachslice in a file (F_(ij)) thereby generating at least one set of files,said server comprising: means for receiving an initial request directedto a multimedia content from a client device, means for sending adocument to said client device upon reception of said initial request,said document causing said client device to repetitively send a fetchingrequest designating said multimedia content, means for selecting atleast one file amongst said set(s) of files, upon reception of saidfetching requests from said client device, and means for downloading theselected file(s) to said client device.
 2. A server as claimed in claim1, wherein said document contains a resource identifier designating saidmultimedia content and specific to said client device, and causes saidclient device to repetitively send fetching requests containing saidresource identifier, and said server comprises: means, activated uponreception of a first fetching request, for selecting a first file to bedownloaded amongst said set(s) of files and for keeping a record of saidresource identifier together with an indication of the selected file,and means, activated upon reception of subsequent fetching requests, forchecking said record in order to select the next file to be downloadedand for updating said record.
 3. A server as claimed in one of claims 1or 2, wherein said document comprises an instruction for the clientdevice to send a subsequent fetching request before the end of theplayback of the file that was downloaded in response to the previousfetching request.
 4. A server as claimed in claim 2, comprising meansfor selecting a file to download based on a jump indication contained insaid fetching request.
 5. A method for downloading an encoded multimediacontent to a client device, said method comprising the steps of:encoding a multimedia content, slicing said encoded multimedia contentin at least one set of slicing positions forming at least one set ofslices that can be decoded independently one from the other, enclosingeach slice in a file thereby generating at least one set of files,receiving an initial request from a client device, said initial requestbeing directed to said multimedia content, sending a document to saidclient device upon reception of said initial request, said documentcausing said client device to repetitively send a fetching requestdesignating said multimedia content, selecting at least one file amongstsaid set(s) of files, upon reception of said fetching requests from saidclient device, and downloading the selected file(s) to said clientdevice.
 6. A method as claimed in claim 5, wherein said documentcontains a resource identifier designating said multimedia content andspecific to said client device, and causes said client device torepetitively send fetching requests containing said resource identifier,and said method further comprises the steps of: upon reception of afirst fetching request, selecting a first file to be downloaded amongstsaid set(s) of files and keeping a record of said resource identifiertogether with an indication of the selected file, and upon reception ofsubsequent fetching requests, checking said record in order to selectthe next file to be downloaded and updating said record.
 7. A method asclaimed in one of claims 5 or 6, said document comprises an instructionfor the client device to send a subsequent fetching request before theend of the playback of the file that was downloaded in response to theprevious fetching request.
 8. A method as claimed in claim 6 whereinsaid step of selecting a file to download takes into account a jumpindication contained in the received fetching request.
 9. A networksystem comprising at least: a source (1) for acquiring a multimediacontent, an encoder (5) encoding said multimedia content, a slicer (6)for slicing said encoded multimedia content in at least one set ofslicing positions forming at least one set of slices that can be decodedindependently one from the other, and for enclosing each slice in a filethereby generating at least one set of files, a distribution network(10), an access provider (12) for providing a client device (14) with anaccess to said distribution network, and a server (8) as claimed inclaims 1 to
 4. 10. A computer program comprising instructions forimplementing a method as claimed in claims 5 to 8 when said program isexecuted by a processor.